Architecture Overview

Detailed Architecture Diagram

The following diagram is an example of a Resolve Actions Pro install using an N-node cluster array.

Architecture Overview

The Actions Pro architecture consists of five primary components and a database. The general purposes of the components can be divided into:

• User interface (RSView)
• Runbook execution (RSControl and RSRemote)
• Data storage (RSSearch and Database)
• Communication (RSMQ)
• Self-monitoring (RSMgmt).

Components

Actions Pro components include the following:

Component	Description
RSMQ	AMQP message bus used by the other components (except RSSearch) to communicate with each other. Manages communications between Actions Pro components and provides the JMS Messaging Service. It operates as Primary and Backup and typically runs on two nodes of the cluster. It may be deployed and run on separate servers for extremely high loads.
RSView	Hosts the Actions Pro user interface. The RSView is the Web user interface for the application. It provides both the UI for end users as well as Runbook developers within the same web application. The RSView is clustered and must be in close proximity to other RSViews and the database.
RSControl	Coordinates all Runbook and ActionTask execution. RSControl performs the decision-making and assessment of the Automation Model. The RSControl is clustered and must be in close proximity to other RSControl nodes and to the database.
RSRemote	Executes the various ActionTasks required by automations. The RSRemote provides the Connectors and APIs to perform actions and queries against external systems. RSRemote can be a deployed standalone, independent of the RSControl and RSView. It does not require access to the database.
RSMgmt	Provides administrative monitoring of deployed components when installed on each server. Monitors local Actions Pro components and gathers metrics for reporting.
RSSearch	Manages all Actions Pro data retention for Runbook results and indexes documents

Connection Types

The following diagram shows the components of Actions Pro and the request execution flow.

In the above diagram, the following connection types are used:

Connection Type	Description
HTTP/S Connection	This is the communication between the RSViews hosting the UI, and the user-preferred web browser (Firefox, Chrome, or IE)
AMQP Messages	AMQP asynchronous messages are used by various components to communicate with each other (such as sending Runbook requests or ActionTask results)
State Replication	This is used to communicate state information between clustered like components
JDBC Connection	The RSView, RSControl, and RSMgmt can all communicate with the database set up with Actions Pro
Adaptors/Gateways	The RSRemote components can be configured to communicate with other servers or tools with in-build adaptors and components
Active Directory/LDAP	The RSViews can be set up to use an AD or LDAP server for user authentication
ElasticSearch	Runbook results are written to and read from Elasticsearch (Elasticsearch is also used to index Document and ActionTask content for sear

RSControl

The RSControl is primarily responsible for coordinating Runbook execution. It is also responsible for executing the Preprocessor, Parser, and Assessor portions of ActionTasks. RSControl performs the decision-making and assessment of the Automation Model. It can be clustered with any number of RSControls and must be close to other RSControl nodes and to the database. Increasing the number of RSControls in a cluster increases the number of Runbook executions the cluster can handle.

Configuring the RSControl component is managed through the blueprint.properties file which contains all configuration settings. For further instructions on how to use the Blueprint see RSControl Settings in Blueprint Configuration.

Communication

The following table describes the different tools and default ports that RSControl requires when installed:

Communication Protocol	Port	Description
AMQP	4004	Used to send and receive messages from the other Actions Pro components.
JDBC	3306,1521	A database connection pool is used to pull runbook and action task details for execution, and optional to archive runbook execution data to the database.
RSSearch	9300	Runbook results are eventually written to RSSearch (Elasticsearch).

RSRemote

The RSRemote is primarily responsible for executing the Content portion of ActionTasks and for communicating with various servers and other tools as needed. It provides the Connectors and APIs to perform actions and queries needed for communication with external systems. RSRemote is also commonly placed stand-alone behind firewalled or sectioned-off areas of networks to allow a central Actions Pro cluster to execute automations that require access to these areas. It can also be used to handle Active Directory or LDAP authentication for the RSViews.

Gateways

The RSRemote can be configured to use various gateways (such as Netcool, Remedy). When setting up a gateway on an RSRemote, the first step is to make sure that the relevant "rsremote.receive.gateway.active" property is set to true (e.g. rsremote.receive.netcool.active=TRUE for the Netcool gateway). Each Gateway and its RSRemote blueprint properties are discussed in details RSRemote Settings.

Communication

The following table describes the different tools and default ports that RSRemote requires when installed:

Communication Protocol	Port	Description
AMQP	4004	Used to send and receive messages from the other Actions Pro components.

RSView

The RSView is primarily responsible for hosting the UI for Actions Pro and uses Tomcat. Using it, Runbook developers can define ActionTasks and create Runbooks and wiki document pages, while end users can use the document pages to execute procedures and Runbooks or use Actions Pro Social to collaborate with each other. This component can be clustered and must be close to other RSView and the database.

Active Directory/LDAP Configuration

The RSView can be set up to authenticate users against an Active Directory or LDAP servers. More information on the configuration and setup can be found in RSVeiw Authentication and Authenticate via LDAP/Active Directory sections in Blueprint Configuration.

Communication

The following table describes the different tools and default ports that RSView requires when installed:

Communication Protocol	Port	Description
AMQP	4004	Used to and an receive messages from the other Actions Pro components
JDBC	3306,1521	A database connection pool is used to read and write Runbook, ActionTask, and document details
RSSearch	9300	Runbook results and Runbook result filters are read using indexes from RSSearch (Elasticsearch)
HTTP/S	8080, 8443	Port used by browsers to communicate with the Tomcat server hosting RSView

Updating the RSView SSL Certificate

To update the RSView SSL Certificate, you must update the existing JKS keystore file with a new one containing an updated SSL certificate and key.

note

The password for the key and the keystore must be identical when downloading the new JKS keystore. If the passwords do not match, the Resolve UI may be inaccessible.

How to Replace the RSView JKS Keystore

1. Backup Files
   • Original JKS Keystore: Find the rsview.tomcat.connector.https.keystoreFile in the blueprint.properties.file for the location of the original JKS keystore file.
   • Keystore Password: Find the encrypted password under rsview.tomcat.connector.https.keystorePass in the blueprint.properties file.
2. Download the New JKS Keystore
   • Enter the same password for the keystore and the key.
3. Verify the New Keystore
   • Run the following command to list the contents of the new keystore: /opt/resolve/jdk/bin/keytool -list -v -keystore <path_to_new_jks_keystore>
4. Stop RSView
5. Update the blueprint.properties File -Update the following entries with the new JKS keystore and password:

   rsview.tomcat.connector.https.keystoreFile=
   rsview.tomcat.connector.https.keystorePass=
6. Run the Configuration Script
   • Run config.sh to apply the changes.
7. Restart RSView
8. Confirm the Resolve UI is accessible.

RSMgmt

RSMgmt is responsible for the administrative monitoring of deployed components when installed on a local server. In a multi-node Actions Pro environment, RSMgmt is installed on every node. It monitors local Actions Pro components run updated and upgrades. This component gathers metrics for the Actions Pro cluster that is needed for reporting. RSMgmt sends out automatic alerts for failures through the email gateway, Actions Pro database, the database gateway, and/or SNMP traps.

Communication

The following table describes the different tools and default ports that RSMgmt requires when installed:

Communication Protocol	Port	Description
AMQP	4004	Used to and an receive messages from the other Actions Pro components
JDBC	3306,1521	A database connection pool is used to monitor the local server's database connection and write metric data

RSMQ

RSMQ handles the AMQP (Advanced Message Queuing Protocol) traffic between the different Actions Pro components. It is implemented using RabbitMQ. When RSControl transfers action execution to RSRemote, it puts it on the RSMQ queue. This component operates as a Primary and Backup pair of nodes. In case of extremely high loads of information, it can be deployed and run on separate servers.

Communication

The following table describes the different tools and default ports that RSMQ requires when installed.

Communication Protocol	Port	Description
AMQP	4004	Used to send and receive messages from the other Actions Pro components
EPMD	4369	Port Mapper daemon used for resolution of node names in a RabbitMQ cluster
Inet	35197	Used to communicate information between the different cluster members
RabbitMQ Management	15672	Port used to make runtime configurations to the RSMQ

RSSearch

The RSSearch (Elasticsearch) is responsible for storing Runbook results for viewing and index data for documents, ActionTasks, and Social posts. Elasticsearch is:

• Responsible for event data for Runbook execution and WSDATA
• Handles life-cycle management of Worksheet data (see Data Management for more details)
• It can be used in ActionTasks to share data between different Runbook and task executions on the same Worksheet
• Used in storing the state of Decision Tree navigation.

Communication

The following table lists the different tools and default ports required by RSSearch.

Communication Protocol	Port	Description
TCP	9300	Port used by Actions Pro components to send commands and data
HTTP	9200	Http port that can be used by external tools to gather data on the Elasticsearch status

note

The search TTL can be turned off by setting its value to -1.

Changing the TTL value will only affect new records, and any older records will keep the original TTL with which they were created.

Actions Pro Database

Actions Pro requires that a back-end database be allocated for each standalone or cluster installation. Actions Pro supports Oracle, MySQL, and MariaDB as its back-end database. The RSView, RSControl, and RSMgmt are the components that require database connections. The database must be allocated in advance of installing Actions Pro.

CSRF Guard

CSRF stands for Cross-Site Request Forgery (CSRF), Actions Pro uses OWASP CSRFGuard Project to mitigate CSRF attacks. Even though HTTP POST method is the most vulnerable, since it changes state of the system, it needs to be protected against CSRF attacks. Actions Pro protects HTTP GET method against CSRF attacks as well. Since Actions Pro stores and can display action task results as part of wikis, action task results may contain sensitive data which needs to be protected against CSRF attacks, when wikis are accessed using HTTP GET request. Actions Pro solves these issues by allowing adding URLs to blacklist and whitelist in a file located under <installation folder>/tomcat/webapps/resolve/WEB-INF/csrfguard.properties. For further details about configuring Actions Pro csrfguard.properties refer to CSRF.

Logstash

Logstash is an open source, server-side data processing pipeline that ingests data from a multitude of sources simultaneously, transforms it, and then sends it to your favorite "stash.", in this case Elasticsearch.

As data travels from source to store, Logstash filters parse each event, identify named fields to build structure, and transform them to converge on a common format for easier, accelerated analysis.

Operation

If Logstash nodes happen to fail, Logstash guarantees at-least-once delivery for your in-flight events with its persistent queue.

• This feature operates in the background. It is automatic with Actions Pro installation.
• If Logstash service goes down, it will not cause Actions Pro to be down.
• Events that are not successfully processed can be shunted to a dead letter queue for introspection and replay.
• With the ability to absorb throughput, Logstash scales through ingestion spikes without having to use an external queueing layer.
• There are no additional special system requirements for installation.

Start/Stop

The "run.sh and stop.sh" script is located in the logstash/bin folder, or you can use the main "bin/run.sh and stop.sh" passing in Logstash as the argument.

Turn On/Off Debug

In the advanced settings set;

• "logstash.yml.config.debug" to true (default false)
• "logstash.yml.log.level" to debug (default is info)